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Method and system for allowing code to be securely initialized in a computer 



(57) A memory controller prevents CPUs and other 
I/O bus masters from accessing memory during a code 
(for example, trusted core) initialization process. The 
memory controller resets CPUs in the computer and al- 
lows a CPU to begin accessing memory at a particular 



location (identified to the CPU by the memory control- 
ler). Once an initialization process has been executed 
by that CPU, the code is operational and any other 
CPUs are allowed to access memory (after being reset), 
are any other bus masters (subject to any controls 



as 



imposed by the initiated code). 
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Description 
TECHNICAL FIELD 

[00011 This invention relates to secure code execu- 
tion, and more particularly to a method and system for 
allowing code to be securely initialized in a computer. 

BACKGROUND OF THE INVENTION 

[0002] Having people be able to trust computers has 
become an increasingly important goal. This trust gen- 
erally focuses on the ability to trust the computer to use 
the information it stores or receives correctly. Exactly 
what this trust entails can vary based on the circum- 
stances. For example, multimedia content providers 
would like to be able to trust computers to not improperly 
copy their content. By way of another example, users 
would like to be able to trust their computers to forward 
confidential financial information (e.g., bank account 
numbers) only to appropriate destinations (e.g., allow 
the information to be passed to their bank, but nowhere 
else). Unfortunately, given the generally open nature of 
most computers, a wide range of applications can be 
run on most current computers without the user's knowl- 
edge, and these applications can compromise this trust 
(e.g., forward the user's financial information to some 
other destination for malicious use). 
[0003] To address these trust issues, different mech- 
anisms have been proposed (and new mechanisms are 
being developed) that allow a computer or portions 
thereof to be trusted. Generally, these mechanisms en- 
tail some sort of authentication procedure where the 
computer can authenticate or certify that at least a por- 
tion of it (e.g., certain areas of memory, certain applica- 
tions, etc.) are at least as trustworthy as they present 
themselves to be (e.g., that the computer or application 
actually is what it claims to be). In other words, these 
mechanisms prevent a malicious application from im- 
personating another application (or allowing a computer 
to impersonate another computer). Once such a mech- 
anism can be established, the user or others (e.g., con- 
tent providers) can make a judgment as to whether or 
not to accept a particular application as trustworthy (e. 
g., a multimedia content provider may accept a particu- 
lar application as being trustworthy, once the computer 
can certify to the content provider's satisfaction that the 
particular application is the application it claims to be). 
However, installing such mechanisms on a computer 
can be difficult, as they require protection against a ma- 
licious application interfering with the mechanism (e.g., 
a malicious application impersonating the trusted mech- 
anism). 

[0004] One solution is to build a computer that in- 
cludes a trustworthy mechanism for booting the compu- 
ter. However, booting a computer typically involves us- 
ing various pieces of code, often referred to as the basic 
input output system (BIOS) and potentially many option 



read only memories (ROMs) or BIOS extensions, that 
operate to load the operating system from some other 
storage device (typically a hard disk drive). Thus, a trust- 
worthy mechanism for booting the computer would re- 

5 quire that the BIOS be trustworthy, each of the option 
ROMs be trustworthy, and each of the BIOS extensions 
be trustworthy, before a trustworthy operating system 
can be loaded into the computer. Not only is it difficult 
to have each of these components trustworthy, but the 

10 BIOS, option ROMs, and BIOS extensions are frequent- 
ly stored on devices that can be re-written in the com- 
puter (e.g. : Flash memory), and thus the integrity thereof 
compromised. Therefore, building a computer that in- 
cludes a trustworthy mechanism for booting the compu- 

15 ter can be problematic. 

[0005] The invention described below addresses 
these disadvantages, providing a method and system 
for allowing code to be securely initialized in acomputer. 

20 SUMMARY OF THE INVENTION 

[0006] A method and system for allowing code to be 
securely initialized in a computer is described herein. 
[0007] According to one aspect, a memory controller 

25 prevents CPUs and other I/O bus masters from access- 
ing memory during a code (for example, OS, microker- 
nel, or other trusted core) initialization process. The 
memory controller resets CPUs in the computer and al- 
lows a CPU to begin accessing memory at a particular 

30 location (identified to the CPU by the memory control- 
ler). Once an initialization process has been executed 
by that CPU, the code is operational and any other 
CPUs are allowed to access memory (after being reset), 
as are any other bus masters (subject to any controls 

35 imposed by the initiated code). 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0008] The present invention is illustrated by way of 
40 example and not limitation in the figures of the accom- 
panying drawings. The same numbers are used 
throughout the figures to reference like components 
and/or features. 

[0009] Fig. 1 is a block diagram illustrating an exem- 
45 piary computer in accordance with certain embodiments 
of the invention. 

[0010] Figs. 2 and 3 illustrate exemplary manners in 
which a trusted core can be implemented. 
[001 1 ] Fig. 4 illustrates an exemplary computer archi- 
50 tecture employing distributed memory controllers in ac- 
cordance with certain embodiments of the invention. 
[0012] Fig. 5 is a flowchart illustrating an exemplary 
process for a code initialization process in accordance 
with certain embodiments of the invention. 

55 

DETAILED DESCRIPTION 

[0013] A method and system for allowing code (e.g., 
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software instructions) to be securely ' n,tia ' ,zed '"^ n 
puter is described herein. This secure code '"«on 
orocess is described primarily with reference to inrt.al.z- 
Z alrlJted core in a computer. However, the secure 
co 9 de inftia.ization process can be used tc .secure* ini- 
tialize any of a wide variety of types of code, without 
regard Jhow trustworthy the code is. The ™chan.sm 
described herein is of particular interest becaus , no 
changes to the core-CPU, and few changes to the CPU 

S'ttTeSS being -trusted" refe* to 
code that is immutable in nature and immutable .n .den- 
tity Code that is trusted is immune to be.ng tampered 
with by other parts (e.g . code) of the computer and it can 
be reliably and unambiguously ident,f.ed. In other 
w^rotfny^therent^orc.mponentasKing^tms 

code- can be told "this is code xyz" , and can be assured 
both that the code is indeed code xyz (rather than some 
imposter)and that code xyzis unadulterated. Trust does 
nof deal with any quality or usefulness aspects , rfl he 
code - only immutability of nature and immrtHy o 
identity. The method and system described herein can 
be used to allow trusted code to know that it parted ex- 
ecution in an orderly state, providing immutab.l.ty of .n- 
malizat.on. ^ ^ ^ ^ i„ us tratin g an exem- 

plary computer 1 00 in accordance with certain embod- 
SnSiTtf the invention. Computer 100 is intended to 
present a wide variety of computing devices, such as 
personal computers (PCs), hand-held or pocket devic- 
es, persona, digital assistants (PDAs), gamins , con- 
so es, Internet appliances, multiprocessor or s^ 
nrocessor systems, microprocessor-based or program- 
Sconsumer electronics, network PCs.m.n.cornput- 
ers, mainframe computers, embedded systems etc 
[0016] Computer 100 includes one or more central 
processing units (CPUs) or processors 102, 104, a 
memory controller 106, an I/O controller 108, and sys- 
tem memory 110. CPUs 102 and 104 represent any of 
a wideTariety of processors, such as x86-architecture 
^compatible) processors, PowerPC-architecture or 
compatible) processors, etc. Although multiple (n) 
CPUs 102, 104 are illustrated in Fig. 1, computer 100 
can alternatively be implemented with only a sjngte 
CPU The CPUs 102, 104 are coupled together and to 
memory controller 1 06 via a processor bus 11 2. 
[00171 Memory controller 106 is illustrated as a sep- 
arate component, but may alternatively be incorporated 

into another component or device, such as a bridge i in- 
cluding an interrupt controller, accelerated graphics port 
(AGP) etc. Memory controller 106 communicates with 
CPUs 102 104, I/O controller 108, and memory 110. 
Memory 110 represents a system memory, such as a 
rlndom accessmemory (RAM). I/O controller 108 op- 
erates as a bridge or interface between various I/O de- 
vices coupled to an I/O bus 114 and other components 
within computer 100. Any of a wide variety of conven- 
tional I/O devices can be coupled to I/O bus 114. In the 



illustrated example, a mass storage device controller 
116 is coupled to bus 114 and a mass storage device 
e g.. a hard disk) 116, a ROM 120 (including a BIOS 
122 and option ROMs and/or BIOS extensions 124) is 
5 coupled tobus 114, and an adapter controller 1 26 m cou- 
plec I to bus 114 and a network adapter 128 (e.g., net- 
work interface card (MC) or modem). 
0018] Memory controller 106 includes a processor 
bus interface 130, a memory interface 1 32, an I/O .nter- 
10 face 1 34, a control logic (also referred to as a processor 
or controller) 136, a digest 138, two reset vectors 140^ 
142, and initialization parameters 153. Processor bus 
interface 1 30 operates as an interface between memory 
controller 106 and processor bus 112, allowing memory 
,5 controller 106 to receive commands and requests Jrom 
CPUs 102 1 04 as well as communicate responses ana 
commands toCPUs 102, 104. Memory interface 132ojp- 
erates as an interface to system memory 110, a lowing 
controller 106 to read data stored in memory 110 and 
20 wrte datato memory 110. I/O interface 134 operates as 
anTnterface to I/O controller 108, allowing I/O compo- 
nents 118, 120, and 128 to communicate with memory 
controller 106 and vice versa via I/O controller 108Jn 
the illustrated example, communications to andre rom 
2 s acomponentintemaltocontro..er106(e.g.,controlog,^ 
136, reset vectors 140, 142, etc.) are passed through 
the appropriate interface. 

r0019l Selected ones of I/O components coupled to I/ 
O bus 114 may operate as bus masters. A bus master 
so refers to a device (typically other than a CPU I that is 
capable of driving address bus signals and other bus 
control signals on a bus. Examples of bus masters are 
massLragedevicecontrollerllSand network adapter 
controller 126. Bus masters can communicate wrth 
35 memory 110 via I/O controller 1 08 and 106, such as to 
peS direct memory access (DMA) transfers i to an* 
or from memory 110, thereby allev.at.ng a CPU 102. 104 
from having to directly manage such transfers^ 
[0020] in the illustrated example of Fig. 1 , I/O control 
40 ler 108 communicates directly with memory controller 
106 Alternatively, these communications may not pass 
hrough memory 7 controller 106, but rather through a 
processorto I/O bridge (not shown). Additionally, a proc- 
essor to I/O bridge also allows for communications be- 
45 LTen i/O controL 1 08 and CPUs 1 02, 104 on proces- 
sor bus 112. in one implementation, memory controller 
1 06 is included as part of a "chipset" that also .nc.udes 
such a processorto I/O bridge. A chipset refers to a set 
of one or more chips that provides the interfaces be- 
so tween the computer's subsystems and .o^es the 
buses and electronics to allow the CPUs, memory, I/O 
devices, etc. to interact. 

[0021] Control logic 1 36 operates to ensure a trusted 
core can be loaded securely in computer 100, allowing 
55 accesses to memory 110 only under specific c.rcum- 
sSnces as discussedin more detail below. Control logic 
1 36 can be implemented in any of a variety of manners 
such as a microcontroller executing microcode (stored 
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in a nonvolatile secure location (e.g., within controller 
1 06) accessible only to the microcontroller), a program- 
mable logic device or other application specific integrat- 
ed circuit (ASIC), etc. 

[00221 Upon starting-up (e.g., powering-on or reset- 
ting) computer 1 00, the state of memory 11 0 is typically 
not guaranteed. Memory 1 1 0 is typically a dynamic RAM 
(DRAM) which requires periodic refreshing in order to 
maintain its state, so any state would have been lost 
when computer 100 was not powered. Memory 110 can 
be configured to be at a particular state (e.g., storing all 
zeroes or all ones) at power-on, or alternatively memory 
1 1 0 may store random values (e.g. , whatever values the 
individual memory cells stabilized to during power-on). 
Regardless, memory 110 stores no reliable data or in- 
structions upon power-on. It should be noted that the 
contents of memory are more or less random when 
starting-up the entire computer system or just the mem- 
ory However, power-up and/or resetting of the CPU(s) 
do not typically alter the state of the memory (so the con- 
tents of memory are not necessarily random after simply 
resetting a CPU). 

[0023] After computer 1 00 has been powered-on , one 
of CPUs 102 104 will eventually begin executing in- 
structions. Only one of CPUs 102, 104 may initially be- 
gin executing instructions, or alternatively one of CPUs 
102, 104 may be selected to begin booting the compu- 
ter Any of a wide variety of arbitration mechanisms can 
be used to determine which of multiple CPUs is to begin 
booting the computer, such as a pre-configured default 
processor, a distributed arbitration scheme, an arbitra- 
tion device or component (not shown) coupled to proc- 
essor bus 112, etc. . i 
[0024] Regardless of how many CPUs or which CPU 
begins execution of instructions, at least one CPU does 
begin executing instructions. As computer 100 has just 
been powered-on, no instructions are stored in the 
CPU's cache memory (or any other cache memory that 
may be present in computer 100). The CPU obtains in- 
structions from BIOS 122 and begins executing those 
instructions. In one implementation, the CPU is config- 
ured to initially place a read request for a particular ad- 
dress (e.g., FFFFFFF0 16 ) on processor bus 112. Mem- 
ory controller 1 06 responds with the address of a BIOS 
boot block (an address In BIOS 122) at which the CPU 
should begin executing instructions. This address re- 
turned by memory controller 112 is referred to as the 
reset vector, and in this (common) example, is provided 
by external logic. In an alternative implementation, the 
CPU simply begins fetching instructions directly from a 
particular location (for example, 00000000 16 ), so in this 
case the reset vector is f ixed. 

[0025] The CPU then begins loading and executing 
instructions starting with this reset vector. The instruc- 
tions loaded are from ROM 120, andean include instruc- 
tions from BIOS 122 as well as one or more option 
ROMs and/or BIOS extensions 124. Some instructions 
from ROM 120 will result in instructions being loaded 



into memorv 110 (either from ROM 120 or another de- 
vice, suci • mass storage device 118) that are then 
loaded by :: CPU and executed. 
[0026] Vat ous components 1 44 of an operating sys- 
5 tern are thus loaded into memory 110, from ROM 1 20 
and/or other devices (e.g., storage device 118). The 
components 144 can include portions of BIOS 122 as 
well as option ROMs and BIOS extensions 124. OS 
components 144 may also include selected compo- 
10 nents of a general purpose operating system, such as 
any of the Windows® family of operating systems avail- 
able from Microsoft Corp. of Redmond, WA. 
[0027] Eventually, a trusted core is loaded into mem- 
ory 1 1 0 This can be in response to , for example , instruc- 
ts tions in BIOS 122, an option ROM or BIOS extension 
124 an OS component 144, or another application (not 
shown) A trusted core refers to trustworthy code (e.g., 
software instructions) that controls at least a portion of 
the operation of computer 100, and knows how to pro- 
zo tect itself (at least to some extent) on the particular hard- 
ware of computer 100. In protecting itself, the trusted 
core is also able to protect other applications running 
under the control of the trusted core. The amount of pro- 
tection provided by the trusted core, as well as the man- 
25 ner in which such protection is provided by the trusted 
core can vary among computers, computer (or CPU) 
architectures, and trusted cores. The trusted core may 
include all of the functionality of a typical operating sys- 
tem or alternatively only selected functionality. The 
30 trusted core is typically cryptographically certified in 
some manner, allowing the integrity of the trusted core 
to be verified at a latertime. For example, acryptograph- 
ic measure of the trusted core may be extracted from 
the trusted core and stored along with the trusted core 
as on a mass storage device 118 (or on some remote de- 
vice). When the trusted core is later loaded into memory 
1 1 0 a component of computer 1 00 can extract the cryp- 
tographic measure of the trusted core in memory 110 
for comparison to the stored cryptographic measure - if 
40 the two measures match then it can be safely assumed 
that the trusted core has not been altered (e.g., by a 
malicious user or program) while on device 118 or in 
memory 110. 

[0028] In the illustrated example, the extracted cryp- 
45 tographic measure is stored in digest 138. Digest 138 
refers to one or more registers (or other storage mech- 
anisms) used to store a cryptographic measure of the 
trusted core as it is loaded. One such measure is a "cryp- 
tographic digest" that is calculated using a one-way 
so hashing operation, such as SHA-1 (Secure Hash Algo- 
rithm 1). The cryptographic digest has the property that 
it is extremely difficult to find a second pre-image (in this 
case, a second trusted core) that when digested pro- 
duces the same hash value. Hence the digest-register 
55 contains a value that can be considered to uniquely rep- 
resent the trusted core in use. For a basic introduction 
of cryptography, the reader is directed to a text written 
by Bruce Schneier and entitled "Applied Cryptography. 
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Protocols, Algorithms, and Source Code in C," pub- 
lished by John Wiley & Sons with copyright 1 994 (or sec- 
ond edition with copyright 1 996). 
[0029] Alternatively, measures other than a digest can 
be used. For example, the logic could require that the 
trusted core be accompanied by a digital certificate(s). 
The chipset could ensure thatthe certificate (s) matches 
the trusted core image, and then save the certif icate(s), 
a public key(s) obtained from the certificate(s), or a di- 
gests) of the certificate(s) in the register. 
[0030] Eventually, the computer is ready to load and 
initialize the component that will provides the "root of 
trust" for the running computer. A significant problem 
faced in previous computers is that all code that has ex- 
ecuted beforehand can subvert the execution of the 
trusted core by programming the CPUs or other devices 
to misbehave. For instance, a bad 'OS-loader could ar- 
range that a bus mastering controller should, after a brief 
delay, subvert the new component by writing untrusted 
code over it. The invention described herein removes 
all previously executing code from the trust chain. 
[0031] The trusted core can operate in any of a wide 
variety of manners to make itself trustworthy. The man- 
ner in which the trusted core operates can vary, as can 
the amount of security or trustworthiness provided by 
the trusted core. Figs. 2 and 3 illustrate exemplary man- 
ners in which a trusted core can be implemented. Figs. 
2 and 3 : however, illustrate only examples of how the 
trusted core can be implemented, and the trusted core 
can actually be implemented in different manners. Gen- 
erally, the trusted core can use whatever facilities are 
provided by the computer components to protect itself 
once allowed to execute, such as rings, curtaining, etc. 
[0032] It should be noted that the invention described 
herein does not limit the nature of the code that will com- 
prise the "root of trust." It is anticipated that this code 
will take measures (such as programming the CPU 
memory controllers) to protect itself from code it might 
run, or devices it might program. However, the "root of 
trust" may be a full OS, a microkernel, a Hypervisor, or 
some smaller component that provides specific security 
services. Hereafter, we refer to such a component as 
the "trusted core." 

[0033] In Fig. 2, the trusted core is implemented by 
taking advantage of different privilege levels of CPUs 
1 02, 1 04 of Fig. 1 (e.g., rings in an x86 architecture proc- 
essor). In the illustrated example, these privilege levels 
are referred to as rings, although alternate implementa- 
tions using different processor architectures may use 
different nomenclature. The multiple rings provide a set 
of prioritized levels that software can execute at, often 
including 4 levels (Rings 0, 1 , 2, and 3). Ring 0 is typi- 
cally referred to as the most privileged ring. Software 
processes executing in Ring, 0 can typically access 
more features (e.g., instructions) than processes exe- 
cuting in less privileged Rings. Furthermore, a proces- 
sor executing in a particular Ring cannot alter code or 
data in a higher priority ring. In the illustrated example, 



a trusted core 1 60 executes in Ring 0, while an operating 
system 1 62 executes in Ring 1 and applications execute 
in Ring 3. Thus, trusted core 160 operates at a more 
privileged level and can control the execution of operat- 
5 ing system 162 from this level. Additionally, the code 
and/or data of trusted core 1 60 (executing in Ring 0) 
cannot be altered directly by operating system 162 (ex- 
ecuting in Ring 1) or applications 1 64 (executing in Ring 
3). Rather, any such alterations would have to be made 
10 by the operating system 1 62 or an application 164 re- 
questing trusted core 160 to make the alteration (e.g., 
by sending a message to trusted core 160, invoking a 
function of trusted core 160, etc.). 
[0034] Alternatively, the operating system may be 
15 separated into a memory manager component that op- 
erates as trusted core 1 60 with the rest of the operating 
system operating as OS 1 62 . The trusted core 1 60 then 
controls all page maps and is thus able to shield trusted 
agents executing in Ring 3 from other components (in- 
20 eluding OS 162). In this alternative, additional control 
also needs to be added (e.g., in memory controller 1 06 
of Fig. 1 ) to protect the trusted core from other busmas- 
ters that do not obey ring privileges. 
[0035] In Fig. 3, the trusted core is implemented by 
25 establishing two separate "spaces" within computer 
1 00 : a trusted space 1 66 (also referred to as a protected 
parallel area, or curtained memory) and a normal (un- 
trusted) space 168. These spaces can be, for example, 
one or more address ranges within computer 1 00. Both 
30 trusted space 1 66 and normal space 1 68 include a user 
space and a kernel space, with the trusted core 1 70 be- 
ing implemented in the kernel space of trusted space 
166. A variety of trusted applets, applications, and/or 
agents can execute within the user space of trusted 
35 space 1 66, under the control of trusted core 1 70. How- 
ever, any application 174, operating system 176, or de- 
vice driver 178 executing in normal space 168 is pre- 
vented, by trusted core 170, from accessing trusted 
space 166. Thus, no alterations can be made to appli- 
40 cations or data in trusted space 1 66 unless approved by 
trusted core 170. 

[0036] Returning to Fig. 1 , the trusted core 146 is il- 
lustrated in three portions: a platform trusted core por- 
tion 1 48 , a common trusted core portion 1 50 , and a trust- 
45 ed core data portion 152. Although the portions 148, 
150, and 152 are illustrated as being arranged contigu- 
ously in memory 110, the portions need not be so ar- 
ranged. E.g., different portions can be stored in different 
non-contiguous areas, and different sections of each 
so portion can be stored in different non-contiguous areas. 
Alternatively, depending on the manner in which trusted 
core 146 operates when executing, the portions may 
need to be arranged in physically contiguous locations 
within memory 110 (that is, actually stored in physically 
55 contiguous locations of the RAM, not being paged out 
to another device in accordance with virtual memory). 
[0037] Trusted core data portion 152 is an area of 
memory 1 1 0 that is used to store data used by the trust- 
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ed core. Platform trusted core portion 1 48 includes code 
that is specific to the particular hardware used in com- 
puter 100 (e.g., the specific type of CPU, the type of 
chipset, etc.). Common trusted core portion includes 
code that implements the operation and functionality of 
the trusted core but is not specific to the particular hard- 
ware used in computer 1 00. By separating the two por- 
tions 148 and 150, the specifics of how interaction with 
the hardware of computer 1 00 (e.g., how to set a timer) 
can be abstracted to portion 150 by portion 148, so the 
same common trusted core portion can be used on dif- 
ferent computers. For example, the common trusted 
core code 150 can operate as if all timers were set in 
the same manner, while platform trusted core code 1 48 
operates to convert the instructions from code 150 into 
commands that are actually understood by the underly- 
ing hardware of computer 100. 

[0038] Trusted core 146 can be loaded into memory 
110 from the same source or alternatively different 
sources. By way of example, platform trusted core por- 
tion 148 may be loaded into memory 110 from the 
chipset of computer 100 (the chipset refers to a set of 
one or more chips the provides the interfaces between 
the computer's subsystems, including the buses and 
electronics to allow the CPUs, memory, I/O devices, etc. 
to interact, and may include memory controller 1 06, I/O 
controller 108, and buses 112 and 114), while the com- 
mon trusted core portion 1 50 may be loaded into mem- 
ory 110 from mass storage device 118. By way of an- 
other example, one portion 148, 150, or 152 may be 
loaded into memory 110 from network adapter 128 (e. 
g from a remote server), orthe portions may all be load- 
ed from network adapter 128 but from different sources 
(e g different remote servers). Additionally, different 
parts of one or more of portions 148, 150, and 152 may 
be loaded from different sources (e.g., part of portion 
1 50 may be loaded into memory 110 from mass storage 
device 1 1 8 and another part of portion 150 may be load- 
ed from a remote server via network adapter 1 28). 
[0039] Additionally, each portion may be generated by 
combining various overlaid parts from one or more 
sources. For example, a first part could be read from 
one source (e.g., a local disk) and a second part read 
from another source (e.g., a remote server over the net- 
work), and then the two parts could be combined (e.g., 
exclusive-OR the bits of each part) to generate the por- 
tion. 

[0040] It should be noted that the trusted core 146 
need not be stored in a secure location and/or loaded 
into memory 110 in a secure manner. The trusted core 
146 may be stored on any publicly-accessible (or semi- 
publicly accessible) area, such as mass storage device 
1 1 8, a remote server accessed via network adapter 1 28, 
etc.Rather, a cryptographic measure of trusted core 1 46 
can be verified after loading into memory 110 (and after 
it is protected so that no further modifications by untrust- 
ed code are possible). The cryptographic measure can 
be generated in any of a wide variety of conventional 



manners, and is designed so that any change in the 
trusted core is reflected in the cryptographic measure. 
For example, if a malicious user were to attempt to alter 
the trusted core by deleting or modifying an instruction 
5 (s) or adding a new instruction(s), in an attempt to sub- 
vert the security of the trusted core, that alteration would 
be reflected in the cryptographic measure (so any sub- 
sequently generated cryptographic measure would not 
match a previously generated cryptographic measure 
10 due to the change in the instruction(s)). In one imple- 
mentation, the cryptographic measure is obtained by 
generating a digest value of the trusted core, such as in 
accordance with the well-known SHA, SHA-1 , MD5 
(Message Digest 5), etc. algorithms. 
15 [0041] This cryptographic measure is generated dur- 
ing the secure initialization process described herein, 
and is made subsequently available to challengers (e. 
g., a bank, IT administrator, smart card, etc.). Interpret- 
ing the digest can be done in several ways. It could be 
20 a "well known" value, such as a company publishing the 
expected value of the its trusted core on its web site. 
Alternatively, the company may generate a certificate for 
each trusted core it writes, and ship it with the trusted 
core (or make it available on a web site). This allows 
25 challengers to see the digest and ask for (or look for) a 
certificate that "names" the digest. It should be noted 
that this certificate should not be in the core itself be- 
cause the certificate names the digest. 
[0042] It should be noted that the initialization process 
so described herein does not limit what a user may try to 
run as the "trusted core" - the user can try to run virtually 
any set of instructions as the trusted core. However, if 
the trusted core is tampered with, then the instructions 
attempting to run as the "trusted core" (the tampered 
35 with trusted core) will not be trusted by other parties be- 
cause the tampered with trusted core will have a differ- 
ent cryptographic measure and will not have access to 
keys that are accessible to the non-tampered with trust- 
ed core. 

40 [0043] It should also be noted that the initialization 
process described herein naturally and easily allows a 
computer to run different trusted cores serially at arbi- 
trary times, without re-booting the system. For example, 
the user can begin executing trusted core x, then switch 
45 to executing trusted core y (which may be a different 
version of the trusted core x, or an entirely different trust- 
ed core), and then switch to trusted core z (or back to 
trusted core x), etc. 

[0044] Memory controller 1 06 operates to ensure that 
so trusted core 146 : once loaded into memory 110, can be 
initialized and begin execution in such a manner that any 
previous state of computer 100 does not compromise 
the integrity of the initialization process. It should be not- 
ed memory controller 106 operates to provide a secure 
55 environment in which the trusted core can be initialized. 
However, once the initialization process is completed, 
trusted core 146 is responsible for its own security. Ad- 
ditionally, memory controller 106 does not generate any 
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guarantees or assurances regarding the trustworthi- 
ness or security provided by trusted core 146. 
r00451 Initialization of trusted core 146 refers to be- 
ginning execution of trusted core 146. This initialization 
typically occurs after trusted core 146 has been loaded 
in its entirety into memory 110, although alternative im- 
plementations may allow for some parts of code 1 46 to 
be loaded into memory after the initialization process oc- 
curs. The initialization process is performed by a set of 
trusted core initialization instructions that are part of 
trusted core 1 46 (and maybe part of one or more of por- 
tions 148, 150, and 152). The exact acts performed by 
the initialization process can vary based on the specific 
manner in which the trusted core operates as well as 
the specific hardware of computer 100 (e.g., the CPU 
architecture), but generally include establishing the pro- 
tection provided by the trusted core (e.g., setting up a 
trusted space) and initializing CPUs to use this protec- 
tion One of the things the "initialization code" must do 
is provide a "reset vector" which is left in place, and is 
always ready to deal with, any processor that is reset 
initiated, hot-plug added, etc. By doing this, the trusted 
core ensures its continued integrity in the face of pro- 
found changes in the CPU configuration of the machine 
(e.g. having new ones added on the fly.) 
[0046] Initialization of trusted core 146 begins in re- 
sponse to a "Trusted Core Initialization" command is- 
sued by one of CPUs 102, 104. The Trusted Core Ini- 
tialization command is commonly issued during booting 
of computer 100, although it may occur any time during 
or after computer 1 00 has been fully booted. The Trust- 
ed Core Initialization command is designed to trigger in- 
itialization of the trusted core, and can be implemented 
in any of a wide variety of manners. For example, the 
command could be a write to a particular port, a write to 
a particular address, etc., however, the port or address 
should have the property that the trusted core can pro- 
tect the port or address using whatever protection 
means that hardware provides afterthecore has gained 
control. This is to ensure that once a trusted core is run- 
ning it is not vulnerable to the simple denial of service 
attack that any untrusted code can remove it from mem- 
ory or replace it. Alternatively, if such protection is not 
provided (e.g., the Trusted Core Initialization command 
has to be invoked by some unprotectable port) then it 
may be a "run once" operation which refuses to perform 
its function again until the system has been rebooted^ 
However, such a machine loses the ability to stop and 
start trusted cores or to use more than one trusted core 
per boot. 

[0047] In one implementation, the Trusted Core Ini- 
tialization command includes three parameters: start, 
length of code, and length of memory. The start param- 
eter refers to the location in memory 110 where trusted 
core 146 begins (e.g., the memory address of the first 
instruction of platform trusted code portion 148). Alter- 
natively, especially in embodiments where trusted core 
146 is riot located in physically contiguous memory, a 



memory descriptor list (MDL) can be identified as the 
start parameter, identifying to memory controller 106 
which memory pages include the trusted core. The 
length of code parameter refers to the length (e.g., the 
5 number of bytes) of the code of trusted core 1 46 (e.g., 
the combination of portions 148 and 150, but excluding 
trusted core data portion 152). The length of memory 
parameter refers to the length (e.g., the number of 
bytes) of trusted core (e.g., the combination of all three 
w portions 148, 150, and 152). These parameters are 
passed to memory controller 106 either prior to (or as 
part of) the Trusted Core Initialization command. In one 
implementation, these parameters are loaded by one of 
CPUs 1 02 1 04 into parameter registers 1 53 of memory 
is controller 1 06 prior to issuance of the Trusted Core Ini- 
tialization command. 

[0048] Upon receipt of the Trusted Core Initialization 
command, memory controller 1 06 protects memory 110 
from all CPUs 102, 104 and any other bus masters in 
so computer 1 1 0. Given that CPUs 1 02, 1 04, as well as any 
other bus masters in computer 100, cannot directly ac- 
cess memory 110, but rather have to access memory 
1 1 0 via memory controller 1 06, memory controller 1 06 
can readily protect memory 110 from the CPUs and bus 
25 masters. By protecting memory 1 1 0, memory controller 
106 ensures that other code (e.g., being executed by a 
CPU or controlling another bus master) does not inter- 
fere with the trusted core initialization process. In pro- 
tecting memory 110, memory controller 106 initially al- 
so lows the only access to memory 110 to be the memory 
refresh signals from a memory refresh controller (not 
shown) that allow DRAM to be refreshed and maintain 

its state. ... . 

[00491 On a machine with factored memory - that is, 
35 multiple blocks of memory with multiple memory control- 
lers - multiple different approaches may be used. In one 
approach, the multiple memory controllers coordinate 
with each other to apply the Trusted Core Initialization 
operator across all memories. In another approach, the 
40 memory-controller/memory selected to do the Trusted 
Core Initialization does all of it (so the whole trusted core 
is loaded into one "bank") and other memory controllers 
ignore it. Since all of the trusted core is in a single pro- 
tected memory bank, the activities of the others do not 
45 matter. The selected memory controller still forces the 
behavior of all CPUs, so the platform hardware is set up 
to allow it to do that. 

[0050] Control logic 136 in memory controller 106 also 
sets a trusted core initialization bit 154 within a secure 
so portion 1 56 of memory controller 1 06. This secure por- 
tion 1 56 is secure in that only control logic 1 36 is allowed 
to access the registers and/or memory within secure 
portion156. Secureportion 156 may not be made visible 
to other components in computer 100 external to mem- 
55 ory controller 1 06, or alternatively control logic 1 36 may 
simply ignore (or reject) any commands received at 
memory controller 1 06 attempting to access any register 
or memory within secure portion 156. The trusted core 
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initialization bit 154 allows control logic 136 to know 
whether the trusted core initialization process is in-proc- 
ess, and the use of bit 154 is discussed in more detail 
below. 

[0051] Memory controller 106 can protect memory 
110 in a variety of different manners. In one implemen- 
tation, memory controller 106 prevents CPUs 102, 104 
from issuing read or write requests on processor bus 
112 thereby preventing CPUs 102, 104 from accessing 
memory 110. The manner in which CPUs 102, 104 are 
kept off the bus varies based on the architecture of 
CPUs 102, 104 and processor bus 112 (e.g., in certain 
Intel-architecture implementations, CPUs can be pre- 
vented form issuing read and write requests on the bus 
by asserting a BNR# (Block Next Request) signal on 
processor bus 112, or by issuing a halt (e.g., HLT) com- 
mand to the CPUs which halts the operation of each 
CPU until it is reset). CPUs 102, 104 will eventually be 
allowed to again issue read and write requests on proc- 
essor bus 112, so control logic 136 also compares all 
requests that memory controller 106 receives from a 
CPU 1 02, 1 04 to the address range of trusted core 1 46 
in memor^ 1 1 0 - any request that memory controller 1 06 
receives from a CPU 102, 104 during this trusted core 
initialization process (e.g., with bit 154 set) that is within 
this address range is accepted and responded to in a 
conventional manner, while any such request that is not 
within this address range or that is from a component 
other than a CPU 102, 104 is rejected (e.g., memory 
controller 106 may refuse to acknowledge the request, 
may deny the request, etc.). Alternatively, requests re- 
ceived that are not within this address range may be al- 
lowed, but with the understanding that such areas of 
memory are not protected. 

[0052] Memory controller 106 also prevents other bus 
masters on I/O bus 114 from accessing memory 110. 
Additionally, memory controller 106 can prevent other 
bus masters on I/O bus 114 from affecting cache mem- 
ories (e.g., within a CPU or on bus 112), such as by not 
issuing any such transactions onto bus 112. For exam- 
ple memory controller 1 06 may have I/O controller 1 08 
assert a signal on I/O bus 114 that prevents any of the 
bus masters from issuing read and write requests on bus 
1 1 4. By way of another example, memory controller 1 06 
may simply ignore any memory access requests it re- 
ceives from I/O controller 108, such as by having I/O 
interface 134 deny such requests, refuse to accept or 
acknowledge such requests, etc. Although preventing 
access to memory 110 can be implemented in similar 
fashions for both CPU accesses and I/O bus master ac- 
cesses, it should be noted that no I/O bus master ac- 
cesses are allowed during the initialization process even 
though CPU access are allowed. 
[0053] Memory controller 106 may immediately pro- 
tect memory 110 upon receipt of the Trusted Core Ini- 
tialization command, or alternatively wait for a period of 
time or for some other action to occur before protecting 
memory 1 1 0 . For example, a particular bus master may 



be in the process of a long DMA transfer at the time the 
Trusted Core Initialization command is received, and 
memory controller 106 may opt to let the DMA transfer 
finish. Although the protection of memory 110 may not 
5 be immediate, the trusted core initialization process 
does not proceed until memory 110 is protected. 
[0054] Once memory 110 is protected, control logic 
1 36 generates a digest value based on trusted core 1 46 . 
Alternatively, another component (not shown), such as 
10 a dedicated cryptographic processor, may be temporar- 
ily allowed access to memory 110 in order to generate 
the digest value (or the digest could be held in the cryp- 
tographic-processor, as long as the cryptographic-proc- 
essor works intimately with the memory controller to per- 
15 form the digest operation only when the CPU is perform- 
ing the initialization process (and cannot be fooled by 
untrusted software making this request of the crypto- 
graphic-processor)). This access, however, may be lim- 
ited, such as allowing the cryptographic processor to on- 
20 |y read from memory 1 10. This digest is generated using 
the same cryptographic mechanism as discussed 
above. Control logic 136 then stores the generated di- 
gest value as digest 1 38 in secure portion 1 56 of mem- 
ory controller 1 06. Digest 1 38 can then be used for sub- 
25 sequent certification and/or authentication purposes by 
trusted core 146. 

[0055] Control logic 136 then maps the reset vector 
to a new reset vector, referred to as the initialization vec- 
tor, so that memory controller 1 06 responds to the next 
30 read request for a particular address (e.g., 
FFFFFFF0 16 ) on processor bus 112 with the initializa- 
tion vector. In situations where the CPU always starts 
executing from a known location (rather than using the 
indirection supplied by the reset-vector fetch proce- 
ss dure), control logic 1 36 arranges to issue an instruction 
(s) as the first one or few instructions that are fetched 
from the memory subsystem that causes the CPU to be- 
gin executing instructions at the start of the trusted core 
(e.g., a JUMP operation), or alternatively re-map the 
40 trusted core to appear at the f ixed processor reset vec- 
tor. This initialization vector is the first address of trusted 
core 146. In one implementation, this mapping is ac- 
complished by control logic 136 writing the start location 
of trusted core 1 46 (e.g., received as a parameter of the 
45 Trusted Core Initialization command) as reset vector 
140. Whenever memory controller 106 receives a read 
request for the particular address (e.g., FFFFFFF0 16 ) 
on processor bus 112, control logic 136 checks bit 154 
of secure portion 1 56. If the bit is set, then the mapped 
so reset vector 140 is returned to the requesting CPU as 
the reset vector. However, if the bit is not set, then the 
initial BIOS boot block address is returned to the re- 
questing CPU. 

[0056] Control logic 1 36 then asserts a reset signal to 
55 a CPU on processor bus 1 1 2. 1 n the situation where mul- 
tiple C PUs are on processor bus 1 1 2, the reset signal is 
asserted to all of the CPUs (although alternatively the 
reset signal may be directed to a single CPU). The man- 
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ner in which the reset signal is asserted (and the nature 
of the reset signal itself) can vary based on the architec- 
ture of CPUs 102, 104 and processor bus 112 (e.g., in 
certain Intel-architecture implementations, all CPUs on 
processor bus 1 1 2 can be reset by asserting a RESET* i 
signal on processor bus 112). 

[0057] Alternatively, other mechanisms can be used 
to reset the CPUs on processor bus 112. The goal of 
resetting a CPU is to clear the CPU of its state (e.g., all 
instructions and data that may reside within registers, < 
caches, buffers, etc. of the CPU) so that that prior state 
cannot compromise the execution integrity of the trusted 
core initialization process. For example, so that instruc- 
tions of a malicious application that are stored in a 
CPU's cache cannot compromise the integrity of the 
trusted core initialization process. 
[0058] In addition to resetting the CPUs on processor 
bus 112, any other cache memory or other device on 
processor bus 112 that includes memory is reset. For 
example, an additional L3 cache (not shown) may also 
be coupled to processor bus 1 1 2, in which case control 
logic 1 36 would reset that L3 cache as well as the CPUs. 
These additional cache memories or other devices on 
processor bus 112 can be reset in any of a variety of 
manners, such as writing random values to the memo- 
ries, writing a string of zeroes or ones to the memories, 
removing power from the memories (e.g., temporarily 
not refreshing DRAMs), issuing specific bus transac- 
tions to invalidate entire caches or specific cache-line 
entries, etc. 

[0059] After resetting CPUs 1 02, 1 04 (and any other 
caches or devices on processor bus 112 (except mem- 
ory controller 106)), memory controller 106 allows one 
of the CPUs on processor bus 112 to access memory 
110. In the illustrated example, any of the CPUs 102, 
104 can be initially allowed to access memory 110 (al- 
though only one is allowed). Memory controller 106 can 
determine which of multiple processors to allow to ac- 
cess memory 110 in any of a variety of manners, such 
as some p re-determined setting, a random determina- 
tion, allowing some external (or CPU-internal) bus arbi- 
tration mechanism to determine, etc. 
[0060] For the purposes of discussion, assume that 
memory controller 1 06 determines to allow CPU 1 02 to 
access memory 110. Memory controller 1 06 then allows 
CPU 102 to access processor bus 112 (all other CPUs 
104 are still prevented from accessing processor bus 
1 1 2). Once a CPU is reset, the CPU will have no instruc- 
tions (or at least no instructions or data that the CPU will 
read) in any of its caches or buffers. CPU 102 will thus 
request instructions to execute by asserting the partic- 
ular address (e.g., FFFFFFF0 16 ) on processor bus 112. 
Memory controller 106 receives this request, control log- 
ic 1 36 determines that trusted core initialization process 
bit 154 is set, so memory controller 106 returns reset 
vector 140 to CPU 102. Also upon receipt of the partic- 
ular address (e.g., FFFFFFF0 16 ) control logic sets an 
additional per-processor vector bit 158. This bit 158 al- 



lows control logic 136 to know, in the event another par- 
ticular address (e.g.. FFFFFFF0 16 ) is received, that re- 
set vector 140 has already been returned to another 
processor. The use of bit 1 58 is discussed in more detail 
5 below. 

[0061] Upon receipt of reset vector 1 40, CPU 1 02 is- 
sues a read request onprocessor bus 1 1 2 for the mem- 
ory address in reset vector 140, which is the initial in- 
struction in trusted core 146 (and the initial instruction 
10 in the trusted core initialization process). CPU 102 thus 
begins to execute the trusted core code 1 46. Since CPU 
102 was reset, no instructions (e.g., malicious code) 
previously loaded into CPU 102 can affect its execution 
of trusted core 146. Additionally, since all other bus mas- 
ts ters are prevented from accessing memory 110, they 
cannot alter the code 146 being fetched and executed 
by CPU 102 from memory 110. 

[0062] CPU 1 02 continues to fetch and execute trust- 
ed core code 146, which initializes the trusted core in 
20 computer 100. As discussed above, the exact manner 
in which the trusted core is initialized can vary based on 
the architecture of computer 100, CPUs 102, 104, the 
type of trusted core being implemented, etc. As part of 
this initialization process, if trusted core 146 supports 
25 multiple processors, an additional CPU start vector is 
loaded as reset vector 142. This additional CPU start 
vector identifies the memory address in code 1 46 where 
additional instructions are to be fetched in the event ad- 
ditional processors begin executing instructions. This 
30 second reset vector can be used, for example, to have 
additional processors begin executing instructions else- 
where in the trusted core than the beginning of trusted 
core 146 (e.g., other than the beginning of the trusted 
core initialization part of code 146). However, since no 
35 other CPU is allowed to run until the "End of initializa- 
tion" the vector at 142 won't be used until after "End of 
Initialization". 

[0063] Eventually the trusted core initialization proc- 
ess completes, and an "End of Initialization" command 
40 is issued by CPU 102. The End of Initialization com- 
mand can be asserted in any of a variety of manners, 
analogous to the Trusted Core Initialization command 
discussed above. Upon receipt of the End of Initializa- 
tion command, memory controller 1 06 allows all remain- 
45 ing CPUs 1 04 on processor bus 1 1 2 to access memory 
110. Each of these CPUs 104, having been reset, will 
have no instructions (or at least no valid instructions) in 
any of their caches or buffers. Each CPU 104 will thus 
request instructions to execute by asserting the partic- 
so ular address (e.g., FFFFFFF0 16 ) on processorbus 112. 
Memory controller 106 receives these requests : control 
logic 1 36 determines that additional processor vector bit 
1 58 is set, so memory controller 1 06 returns reset vector 
142 to each of CPUs 104. 
: 55 [0064] Control logic 1 36 then clears the trusted core 
initialization bit 154, as the trusted core initialization 
i process is complete. Memory controller 1 06 also ceases 

preventi ng other bus masters 1 1 0 from accessi ngmem- 
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orv 110 Thus, any additional protection against mata- 
cls code from another bus master is to be prevented 
by the Execution of the trusted core 146, not memory 

jQotsTEach CPU 104. upon receipt of reset vector 
4 2 !]suesaread request on processor bus112forthe 
™ fririLs in reset vector 142, which is an .nstruc- 
S~eU 6 et Each CPU 104thu S W 

:rc7ucr s ^^ 

^us code) previousiy .oaded into the CPU 104 can af- 
fect its execution of trusted core 1 46. 
F00661 In one implementation, one or more of CPU 
102 104 may need microcode loaded into it .n order to 
luncZ wer*. This microcode may, for example oc 
erroi or'other bugs in the CPU, expose a different >n- 
struction set than the native instruct.cn set o the CPU 
etc This microcode can be included in trusted core 1 46 
(e g in Tusted core data portion 152) and instructions 
■ SJId In the trusted core initialization process to load 

he Authenticity of the microcode may be venhed such 
as by re-computing a digest and comparing 
«fied digest within the microcode (e.g., placed there by 
the author or distributor of the microcode) to ensure , that 
the microcode has not been altered since be.ng s.gned 
by the distributor of the microcode. - n 06 

[00671 In one implementation, memory controller 106 
provides the following assurances ,n response to a 
Trusted Core Initialization command: 

. All I/O access to memory stops. No component can 
Access memory except the refresh contro.ler and 

. of the trusted core is 

after it has been reset. 

. A » CPUs begin executing instructions at one of two 
locations in the trusted core code, and that these 
locations are set from the trusted core code. 

. Sty one of the CPUs will begin executing .nttu* 
°ons at one of the two locations, all others w..l wart 
unti the end of the trusted core initializer .process 
and begin executing instructions at the other of the 

. no° SSI to memory is allowed until me trusted 
core initialization process has completed. 



[0068] in addition, memory contro.ler 106 may - .too 
ooerate to intercept and disallow any interrupts. For ex- 
am^Tmemory controller 106 may include, or alterna- 
tely beTn communication wrth, the interrupt contro er 
s) or computer 100. Any interrupt received during the 
rusted core initialization process can be disallowed^AI- 

lemiively, memory controller 1 06 £ 
self with interrupts (e.g., because the CPUs 1 02 104 
are reset, and limited by memory controller 106 and 



trusted core 146 in their ability to obtain instructions)^ 
iSl Additionally, in certain embodiments, the trust- 
^«ationprocess establishes cer^n = s 
oi memory (either real and/or virtual 
s within the protected or curtained space of the trusted 
corouring operation of the trusted core, the trusted 
coS'operatls to ensure that only trusted 
exiting within that protected space can^ other 
memory addresses within that protected space. In these 
to ornaments, all controls of memory ;o-J-£1££ 
a addressable portions of controller 106, such as pa 
Leter registers' 153) are 

codefromre-LuingtheTrustedCore lnitial.zat.on com- 

So70] in certain implementations. CPUs W 104 
20 support two modes of operation: a real mode and a pro 
S mode. Real mode refers to offering the program- 
ing environment of a predecessor CPU (e.g the nte. 
SS processor), while protected mode makes all n- 
structions and architectural features of the CPU ava «a 
25 b eTthese implementations. CPUs 102 104 are - 
tialized into real mode at power-on (and .n response to 
a RES ET# signal). The trusted core .nlt.aU.at.or , proc- 
ess begins, for each CPU . by transrt.on.ng that CPU into 
Detected mode and then turning memory paging on 
so Cmo^Pagingreferstovirtualmemory.where-pages 

oTmemory can be referenced by the CPU and swapped 
bemeen memory 110 and another storage dev.ce {e.g., 
device 11% as needed). Care should thus be tttonn 
fhe Ssted core initialization process that for additional 
35 Sisfafterthe inftia. CPU) that are reset and pemnitted 
to access memory, they be able to run in rea, mode for 
onTenoug^ to be transitioned to protected mode and 
Lrnino turned on This can be accomplished, for exam- 
ple" oy'careln selection of the additional processor start 

40 SV™"*^ code externa, to the trusted 
c^re^^ 

Sre programmat.ca.ly, and is typically possible ^on ^PC- 
class machines), then the processor will start up by ex- 
45 eating the trustedoore, and not code that can potea- 
^subvert a running core. In this case, the core may 
choose to treat this as an exception condition and de- 
stroy all existing internal state (clear memory), or can 
Reaction to continue execution (forexampU , reload 
so the CPU protection profile that was in effect before the 

fooSritsho 6 ! be noted that the trusted core initial- 
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CPUs. 

[0073] Although discussed herein as primarily per- 
formed during booting of a computer, the trusted core 
initialization process can be performed at different 
times. For example, the trusted core may not be loaded 5 
into memory 110 and the Trusted Core Initialize com- 
mand issued until an application that requires the trust- 
ed core to operate is to be executed (e.g., the user is 
going to download multimedia content that needs to be 
protected). Additionally, the trusted core initialization 10 
process can be repeated multiple times. By way of ex- 
ample, the trusted core code may have a 'Terminate 
Trusted Core" command that terminates execution of 
the trusted core. However, the trusted core could again 
be loaded into memory 110 (if it were actually removed 15 
as part of the execution termination) at a later time, and 
the trusted core initialization process repeated for the 
trusted core code to begin executing again. And, multi- 
ple different trusted cores can be run, one at a time, one 
after the other. 20 
[0074] Additionally, it should be noted that after the 
trusted core initialization process has completed and 
other CPUs are allowed to access memory, these addi- 
tional CPUs need not have been present in the compu- 
ter when the trusted core initialization process began. 25 
By way of example, the computer may support the ability 
to "hot-plug" CPUs (add CPUs to the computer while the 
computer is running). Any such newly added CPUs are 
allowed to access memory, starting execution of instruc- 
tions at the additional processor reset vector. so 
[0075] Fig. 1 illustrates an exemplary architecture 
where a single memory controller 106 controls access 
to memory 110. Alternatively, the trusted core initializa- 
tion process may be implemented in architectures 
where there are multiple memory controllers. 35 
[0076] Fig. 4 illustrates an exemplary computer archi- 
tecture employing distributed memory controlles in ac- 
cordance with certain embodiments of the invention. 
Computer 200 is illustrated including multiple (m) CPUs 
202, 204 coupled to a processor bus 206. CPUs 202, 40 
204 communicate with various I/O components (not 
shown) via a bridge 208. Additionally, each CPU 202, 
204 includes a memory controller 210. The individual 
memory controllers 210 implement a distributed mem- 
ory controller architecture that performs analogous 45 
functions as memory controller 106 of Fig. 1 , except that 
the individual controllers 210 are distributed across mul- 
tiple CPUs. The distributed memory controller architec- 
ture can be implemented in any of a wide variety of con- 
ventional manners, and may include additional cou- 50 
plings (not shown) between the individual memory con- 
trollers 210 to allow communications to be passed 
among the memory controllers 21 0 (e.g., for synchroni- 
zation of the individual memory controllers 210). 
[0077] In the example of Fig. 4, each CPU includes 55 
its own directly attached memory. The bus logic and pro- 
tocols included in computer 200 ensure that each CPU's 
view of the overall memory subsystem remains coher- 



ent. Such memory architectures are often referred to as 
cache-coherent non-uniform-memory-access systems 
(CC-NUMA). Alternatively, ratherthan each CPU having 
its own attached memory, the memory controllers may 
be distributed among the multiple CPUs, but access a 
single shared system memory. 

[0078] Fig. 5 is a flowchart illustrating an exemplary 
process for a code initialization process in accordance 
with certain embodiments of the invention. The process 
of Fig. 5 is implemented by a computer, such as com- 
puter 1 00 of Fig. 1 or computer 200 of Fig. 4, and may 
be implemented in software. The process of Fig. 5 may 
be used for a trusted core initialization process, or alter- 
natively an initialization process for other code. 
[0079] Initially, the normal boot process for the com- 
puter is started using the not necessarily secure BIOS 
(act 252). Eventually, the code is loaded into memory 
{act 254) and an Initialize Code command received <act 
256). In response to the Initialize Code command, mem- 
ory is protected from all processors and bus masters 
(act 258). A cryptographic measure of the code in mem- 
ory is then extracted and stored in a secure location (act 
260). The processor reset vector is then mapped to an 
initialization vector (act 262), such as the start of the 
code in the memory. 

[0080] Once the processor reset vector is mapped to 
the initialization vector, all the processors are reset (act 
264) and one of the processors is allowed to access 
memory (act 266). The process then waits for the proc- 
essor that is allowed to access memory to execute a 
code initialization process from the memory {act 268). 
The end of the code initialization process is signaled, for 
example, by a command issued from the processor ex- 
ecuting code initialization process. Once the code ini- 
tialization process is finished, the processor reset vector 
is re-mapped to an additional processor start vector (act 
270). Any other processors in the computer are then al- 
lowed to access memory (act 272) , as are any other bus 
masters in the computer (act 274). 
[0081] In the discussion herein, embodiments of the 
invention are described in the general context of proc- 
essor-executable instructions, such as program mod- 
ules or code, being executed by one or more conven- 
tional processors or controllers (e.g., control logic 136 
of Fig. 1). Generally, program modules or code include 
routines, programs, objects, components, data struc- 
tures, etc. that perform particular tasks or implement 
particular abstract data types. In a distributed environ- 
ment, program modules or code may be located in mul- 
tiple memory storage devices. 

[0082] Alternatively, embodiments of the invention 
can be implemented in hardware or a combination of 
hardware, software, and/or firmware. For example, all ^ 
or part of the invention can be implemented in one or 
more application specific integrated circuits (ASICs) or 
programmable logic devices (PLDs). 
[0083] Computing devices (such as device 1 00 of Fig. 
1 or device 200 of Fig. 4) typically include at least some 
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form of computer readable media. Computer readable 
media can be any available media that can be accessed 
by a computing device. By way of example, and not lim- 
itation, computer readable media may comprise compu- 
ter storage media and communication media. Computer 
storage media includes volatile and nonvolatile, remov- 
able and non-removable media implemented in any 
method or technology for storage of information such as 
computer readable instructions, data structures, pro- 
gram modules or other data. Computer storage media 
includes, but is not limited to, RAM, ROM, EEPROM, 
flash memory or other memory technology, CD-ROM, 
digital versatile disks (DVD) or other optical storage, 
magnetic cassettes, magnetic tape, magnetic disk stc- - 
age or other magnetic storage devices, or any other me- 
dia which can be used to store the desired information 
and which can be accessed by the computing device. 
Communication media typically embodies computer 
readable instructions, data structures, program mod- 
ules or other data in a modulated data signal such as a 
carrier wave or other transport mechanism and includes 
any information delivery media. The term "modular 
data signal" means a signal that has one or more of its 
characteristics set or changed in such a manner as ko 
encode information in the signal. By way of exampi2 ; 
and not limitation, communication media includes wired 
media such as wired network or direct- wired connection, 
and wireless media such as acoustic, RF, infrared and 
other wireless media. Combinations of any of the above 
should also be included within the scope of computer 
readable media. 

[0084] For purposes of illustration, programs and oth- 
er executable program components such as the operat- 
ing system are illustrated herein as discrete blocks, al- 
though it is recognized that such programs and compo- 
nents reside at various times in different storage com- 
ponents of the computer, and are executed by the data 
processor(s) of the computer. 

Conclusion 

[0085] Although the description above uses language 
that is specific to structural features and/or methodolog- 
ical acts, it is to be understood that the invention defined 
in the appended claims is not limited to the specific fea- 
tures or acts described . Rather, the specific features and 
acts are disclosed as exemplary forms of implementing 
the invention. 



Claims 



1. One or more computer-readable media having 
stored thereon a plurality of instructions that, when 
executed by one or more processors of a computer, 
causes the one or more processors to perform acts 
including: 



allowing operation of the computer to begin 
based on untrusted code; 
loading, under control of the untrusted code, a 
trusted core into memory; 
preventing each of one or more central 
processing units and each of one or more bus 
masters in the computer from accessing the 
memory; 

resetting each of the one or more central 
processing units; 

allowing one central processing unit to access 
the memory and execute trusted core initializa- 
tion code to initialize the trusted core; and 
after execution of the trusted core has been in- 
itialized, allowing any other central processing 
units and any bus masters in the computer to 
access the memory. 

2. One or more computer-readable media as recited 
in claim 1, wherein the one or more processors 
comprise one or more controllers of one or more 
memory controllers. 

3. One or more computer-readable media as recited 
in claim 2, wherein the one or more memory con- 
trollers are distributed among the one or more cen- 
tral processing units. 

4. One or more computer-readable media as recited 
in claim 2, wherein the plurality of instructions com- 
prise microcode to be executed by the one or more 
memory controllers. 

5. One or more computer- readable media as recited 
in claim 1, wherein the untrusted code includes 
code from a basic input output system (BIOS) and 
code from a plurality of option read only memories 
(ROMs). 

40 6. One or more computer- readable media as recited 
in claim 1 , wherein the preventing comprises pre- 
venting each of the one or more central processing 
units and each of the one or more bus masters from 
accessing the memory in response to an initialize 

45 trusted core command received from one of the one 
or more central processing units. 

7. One or more computer-readable media as recited 
in claim 1 , wherein the loading the trusted core com- 
prises copying different portions of the trusted core 
from a plurality of different sources. 

8. One or more computer- readable media as recited 
in claim 1 , wherein the loading the trusted core com- 
prises copying different parts of the trusted core 
from one or more sources and combining the differ- 
ent parts to assemble the trusted core. 
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9. One or more computer-readable media as recited 
in claim 1 , wherein combining the different parts 
comprises exclusive-ORing bits of the different 
parts. 

10. One or more computer-readable media as recited 
in claim 1 , wherein the loading the trusted core com- 
prises copying at least a portion of the trusted core 
from a local mass storage device into the memory. 



10 



11. One or more computer-readable media as recited 
in claim 1 , wherein the loading the trusted core com- 
prises copying at least a portion of the trusted core 
from a remote device into the memory. 

12. One or more computer-readable media as recited 
in claim 1 .wherein the loading the trusted core com- 
prises copying at least a portion of the trusted core 
from a chip of the computer. 

13. One or more computer-readable media as recited 
in claim 1 , wherein the preventing comprises ignor- 
ing all requests for access to the memory from the 
one or more central processing units and one or 
more bus masters. 

14. One or more computer-readable media as recited 
in claim 1 , wherein the plurality of instructions fur- 
ther cause the one or more processors to perform 
acts including: 

extracting a cryptographic measure of the trust- 
ed core in the memory; and 
storing the extracted cryptographic measure. 

15. One or more computer-readable media as recited 
in claim 14, wherein the plurality of instructions fur- 
ther cause the one or more processors to perform 
acts including: 

resetting a cryptographic processor; 
requesting the cryptographic processor to ex- 
tract the cryptographic measure; and 
receiving the extracted cryptographic measure 
from the cryptographic processor. 

16. One or more computer-readable media as recited 
in claim 1 , wherein the resetting each of the one or 
more central processing units comprises asserting 
a processor bus reset signal to each of the one or 
more central processing units. 

17. One or more computer-readable media as recited 
in claim 1 , wherein the plurality of instructions fur- 
ther cause the one or more processors to perform 
acts including: 

mapping a central processing unit reset vector 
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to an initialization vector; 
receiving a read request corresponding to the 
central processing unit reset vector from the 
one central processing unit; 
returning, in response to the read request, the 
initialization vector to the one central process- 
ing unit; and 

allowing the one central processing unit to ac- 
cess the memory beginning with the initializa- 
tion vector. 

18. One or more computer-readable media as recited 
in claim 1 7, wherein the initialization vector is an ad- 
dress within the trusted code in the memory. 

19. One or more computer-readable media as recited 
in claim 17, wherein the plurality of instructions fur- 
ther cause the one or more processors to perform 
acts including: 

re-mapping the central processing unit reset 
vector to an additional central processing unit 
start vector after returning the initialization vec- 
tor to the one central processing unit; and 
returning, in response to any other read request 
corresponding to thecentral processing unit re- 
set vector from another central processing unit, 
the additional central processing unit start vec- 
tor. 

20. One or more computer-readable media as recited 
in claim 1 9, wherein the initialization vector is an ad- 
dress within the trusted code in the memory and 
wherein the additional central processing unit start 
vector and the initialization vector are different ad- 
dresses within the trusted code in the memory. 



21. One or more computer-readable media as recited 
in claim 19, wherein both the initialization vector and 

40 the additional central processing unit start vector 
are obtained from the trusted core. 

22. One or more computer-readable media as recited 
in claim 1, wherein the plurality of instructions fur- 

45 ther cause the one or more processors to perform 
acts including loading microcode from the trusted 
core in memory into the one central processing unit 
after resetting the central processing unit. 

so 23. A method comprising: 

booting, based on untrustworthy code, a com- 
puter; 

loading a trusted core into memory; and 
55 initiating secure execution of the trusted core. 

24. A method as recited in claim 23, further comprising: 
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allowing execution of the trusted core to termi- 

SnitSg secure execution of the trusted 
core without re-booting the computer. 

25. A method as recited in claim 23, further comprising: 

allowing execution of the trusted core to termi- 

toading another trusted core into memory; and 
initiating secure execution of the other trusted 
core. 

26. A method as reeled in c.aim 25, wherein the trusted 
core and the other trusted core are different ver 
sions of the same trusted core. 

27 A method as recited in claim 23, wherein the Initiat- 
fna comprises initiating secure execut.on of the 
^sted core in response to an initialize trusted core 
command received from one of the one or more 
central processing units. 

A method as recited in claim 23, wherein the initiat- 
inrcomprises initiating secure execufon o the 
nuVed core without requiring any additions bus 
tractions to be supported by processors .n the 
computer. 



28. 



26 

cess the memory beginning with the initializa- 
tion vector. 

31 A method as recited in claim 30, wherein the initial- 
' ££n vector is an address within the trusted code 
in the memory. 
32. Amethod as recited in claim 30. further comprising: 

re-mapping the central processing unit reset 
vtcToTto an additional central process.ng unit 
start vector after returning the inif.alizat.on vec- 
tor to the one central processing unit; and 
returning, in response to any other read request 
correspondingtothecentralprocessingumtre- 

setvectorfromanother centra, processing una 
the additional central process.ng unit start vec 
tor. 

20 33 A method as recited in claim 32, wherein the initial- 
izaSn vector is an address within the trusted code 
TZ memory and wherein the add-on* cen£. 
orocessinq unit start vector and the .nrt.al.zat.on 
vSor a^e different addresses within the trusted 
code in the memory. 
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29 A method as recited in claim 23, wherein the initiat- 
fng^ecure execution of the trusted core composes. 

preventing each of one or more central 
processing units in the computer from access- ^ 

of one or more bus masters in 
the computer from accessing the memory, 
resetting each of the one or more central 

St Sm Processing unit to access « 
the memory and execute a trusted core ntah- 

"u~ trusted core inKia.ization 
process, allowing any other centra, process.ng 
units and any of the one or more bus masters 
to access the memory. 

30. A method as recited in claim 29, further comprising: 

mapping a central processing unit reset vector 
to an initialization vector; 
receiving a read request correspond.ng to he 
centra, processing unit reset vector from the 38. 
one central processing unit; 
returning, in response to the read request, the 
Inliza' on vector to the one centra, process- 
inq unit; and 

allowing the one central process.ng unrt to ac- 



34 Amethod asrecited in claim 23, wherein the loading 
trusted core comprises copying different por- 
ZTX trusted core from a 
sources including one or more of: a 
age device, a remote device, and a local ch.pset. 

35 one ormorecomputer-readable memories contain- 
Sg a computer program that is ex«uteblebya 
pScessorto perform the method recrted .n claim 23. 
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36. A method comprising: 

allowing a computer to begin operation based 

SKS2K2£- - - — rthy 

code, additional code into memory and 
initiating execution of the additional code ma 
secure manner despite the untrustworthy code 

in the computer. 

A method as recited in claim 36, wherein 
^further comprises initiating execut.on of the ad- 
dSonal code in a secure manner desprte .both the 
untrustworthy code in the computer and other pre 
existent state of the computer. 

A method as recited in claim 36, wherein the initiat- 
ing execution of the additional code in a secure 
manner comprises: 

preventing each of one or more central 
processing units in the computer from access- 
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ing the memory; 

preventing each of one or more bus masters in 
the computer from accessing the memory; 
resetting each of the one or more central 
processing units; 5 
allowing one central processing unit to access 
the memory and execute a code initialization 
process; and 

after execution of the code initialization proc- 
ess, allowing any other central processing units 10 
and any of the one or more bus masters to ac- 
cess the memory. 

39. A method as recited in claim 36 : wherein the initiat- 
ing comprises initiating execution of the additional 
code in a secure manner without requiring any ad- 
ditional bus transactions to be supported by a proc- 
essor in the computer. 

40. A method as recited in claim 36, further comprising: 20 

mapping a central processing unit reset vector 
to an initialization vector; 
receiving a read request corresponding to the 
central processing unit reset vector from the 25 
one central processing unit; 
returning, in response to the read request, the 
initialization vector to the one central process- 
ing unit; and 

allowing the one central processing unit to ac- so 
cess the memory beginning with the initializa- 
tion vector. 

41 . A method as recited in claim 40, further comprising: 

35 

re-mapping the central processing unit reset 
vector to an additional central processing unit 
start vector after returning the initialization vec- 
tor to the one central processing unit; and 
returning, in response to any other read request 40 
corresponding to the central processing unit re- 
set vector from another central processing unit, 
the additional central processing unit start vec- 
tor. 

45 

42. A method as recited in claim 36, further comprising: 

remapping the trusted core to appear at an ad- 
dress where a central processing unit starts ex- 
ecuting after being reset. 50 

43. A method as recited in claim 36, further comprising: 

receiving, from a central processing unit, a read 
request corresponding to a central processing 55 
unit reset vector; 

responding to the read request with instructions 
to cause the central processing unit to jump to 



a starting location of the trusted core. 

44. A method as recited in claim 36, wherein the loading 
the additional code comprises copying different por- 
tions of the additional code from a plurality of differ- 
ent sources including one or more of: a local mass 
storage device, a remote device, and a local 
chipset. 

45. One or more computer-readable memories contain- 
ing a computer program that is executable by a 
processor to perform the method recited in claim 36. 

46. A memory controller comprising: 

a first interface to allow communication with a 
processor; 

a second interface to allow communication with 
a system memory; and 

a controller, coupled to the first interface and 
the second interface, to reset a processor and 
to allow the processor to execute a code initial- 
ization process while preventing any other 
processors from accessing the system memo- 
ry. 

47. A memory controller as recited in claim 46, wherein 
the memory controller is included in a processor. 

48. A memory controller as recited in claim 46, wherein 
the first interface comprises a processor bus inter- 
face. 

49. A memory controller as recited in claim 48, wherein 
the memory controller operates without requiring 
the processor bus interface to support any addition- 
al commands on the processor bus. 

50. A memory controller as recited in claim 46, wherein 
the system memory comprises a dynamic random 
access memory. 

51 . A memory controller as recited in claim 46, wherein 
the controller is further to allow the processor to ex- 
ecute the code initialization process while prevent- 
ing any bus masters from accessing the system 
memory. 

52. A memory controller as recited in claim 46, wherein 
the controller is further to: 

reset any other processor coupled to the mem- 
ory controller prior to allowing the processor to 
execute the code initialization process; 
prevent any other processor and any bus mas- 
ter coupled to the memory controller from ac- 
cessing the system memory until the one proc- 
ess executes the code initialization process; 
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and 

after execution of the code initialization proc- 
ess allow any other central processing units 
coupled to the memory controller and any bus 
masters coupledto the memory controller to ac- 
cess the memory. 

53. A memory controller as recited in claim 46, wherein 
the controller is further to: ^ 

map a processor reset vector to an initialization 
vector* 

receive a read request corresponding to the 
processor reset vector from the processor; 
return, in response to the read request, the in- 
itialization vector to the processor; and 
allow the processor to access the memory be- 
ginning with the initialization vector. 

54 A memory controller as recited in claim 53, wherein 
' the initializationvectoris an address within the code 
initialization process. 

55. A memory controller as recited in claim 53, wherein 
the controller is further to: 

re-map the processor reset vector to an addi- 
tional processor start vector after returning the 
initialization vector to the processor; and 
return, in response to any other read request 
corresponding to the processor reset vector 
from another processor, the additional proces- 
sor start vector. 

56 A memory controller as recited in claim 55, wherein 
' theinitializationvectorisanaddresswithinthecode 

initialization process and wherein the addrt»naJ 
processor start vector and the in.tial.zat.on vector 
are different addresses within the code initialization 
process. 



memory protector portion comprises a control log.c 
that ignores any request to access the memory re- 
ceived from any bus master. 

61 An apparatus as recited in claim 57, further com- 
" prising a controller, coupled to the memory protec- 
tor portion, to prevent another processor from ac- 
cessing memory until the processor completes ex- 
ecution of the trusted core initialization process. 

62 An apparatus as recited in claim 57, further com- 
' prising acontroller, coupled to the memory protec- 

tor portion, to: 

map a processor reset vectorto an initialization 
vector - 

receive a read request corresponding to the 
processor reset vector from the processor; 
return, in response to the read request, the in- 
itialization vectorto the processor; and 
allow the processor to access the memory be- 
ginning with the initialization vector. 

63. An apparatus as recited in claim 62, wherein the 
controller is further to: 
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57. An apparatus comprising: 

a processor reset portion to assert a reset sig- 
nal to a processor; and 

a memory protector portion to prevent any bus 
master from accessing memory until the proc- 
essor completes execution of a trusted core in- 
itialization process. 

58 An apparatus as recited in claim 57, wherein the ap- 
' paratus comprises a programmable logic device. 

59 An apparatus as recited in claim 57, wherein the 
' processor reset portion comprises a processor bus 

interface. 

60. An apparatus as recited in claim 57, wherein the 
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re-map the processor reset vector to an addi- 
tional processor start vector after returning the 
initialization vector to the processor; and 
return, in response to anotherread request cor- 
responding to the processor reset vector from 
another processor, the additional processor 
start vector. 

64. An apparatus as recited in claim 57, further com- 
prising a storage portion in which a portion of the 
trusted core is stored. 

65 An apparatus as recited in claim 64, wherein the 
' portion of the trusted core stored in the storage por- 
tion comprises a platform trusted core portion. 



66. A computer comprising: 

a processor; 

a bus master; 

a system memory ; and 

a memory controller coupled to the processor, 
the bus master, and the system memory, the 
memory controller being configured to, 

allow access to the system memory from 
the processor and the bus master operat- 
ing based on untrustworthy code, 
reset the processor to begin a trusted core 
initialization process, and 
prevent the bus master from access.ng the 
system memory until after the trusted core 
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initialization process is completed. 

68 A method comprising: 10 
,uwn 9 » computer ,o fe «-boo. e «. 

^lSss^!l•- s --- ,, - y,,^, * 

trusted core. 
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